Estimating memory requirements
To determine memory usage needs, take an inventory of all of the applications and resources on your system that use memory. For OpenEdge-based systems, these processes include:
Operating system memory estimates
Operating system memory usage varies from machine to machine. Operating system buffers are generally a product of how much memory is in the machine. Most systems will reserve 10 to 15 percent of RAM for operating system buffers. Operating system buffers are tunable on most systems. See your operating system product documentation for details.
Understanding memory internals
The primary broker process allocates shared memory for users to access data within the database. The users also use structures within memory to allow for concurrent access to information without corrupting this information. For example, two users who want to update the same portion of memory with different updates could lead to shared memory corruption. Latches prevent this corruption. A latch is similar to a lock. When a process locks a record, it is allowed to update the record without interference from other processes trying to make simultaneous changes. A latch is a lock in shared memory that allows a user to make modification to a memory block without being affected by other users.
Figure 4–3 shows an example of shared memory resources. This illustration should only be considered an example because it is incomplete and is not to scale. Database buffers account for more than 90 percent of shared memory, and the various latch control structures account for less than 1 percent.
As Figure 4–3 illustrates, there are many resources inside of shared memory. Local users (both end-user processes and batch processes) update these structures. If two users access this database simultaneously and both users want to make an update to the lock table (-L), the first user requests the resource by looking into the latch control table. If the resource is available, the user establishes a latch on the resource using an operating system call to ensure that no other process is doing the same operation. Once the latch is enabled, the user makes the modification to the resource and releases the latch. If other users request the same resource, they retry the operation until the resource latch is available.
The database buffers are vitally important. They provide a caching area for frequently accessed portions of the database so that information can be accessed from disk once and from memory several times. Because memory is so much faster than disk, this provides an excellent performance improvement to the user if tuned properly.
The other processes shown in Figure 4–3 are page writers. These Asynchronous Page Writer (APW) processes write modified database buffers to disk. You can have more than one APW per database. The other writers, After-image Writer (AIW) and Before-image Writer (BIW), write after-image and before-image buffers to disk. There can only be a single BIW and a single AIW per database.
Figure 4–4 illustrates how the process of adding remote clients adds a TCP/IP listen socket and server processes. The remote clients send a message to the listen socket, which in turn alerts the broker process. The broker process references the user control table and the server control table to determine if the user can log in and to which server the user can attach. If a server is not available, one server is started, depending on the server parameters for this broker. Parameters such -Mn, -Mi, and -Ma, control the number of servers a broker can start, the number of clients a server can accept, and when new servers are started. See OpenEdge Data Management: Database Administration
for details. Once the proper server has been determined, a bidirectional link opens between that server and the remote client. This link remains open until the user disconnects or the broker is shut down.
OpenEdge-specific memory estimates
OpenEdge uses demand-paged executables. Demand-paged executables, also known as shared executables, reserve text or static portions of an executable that is placed in memory and shared by every user of that executable. For brokers and servers, the dynamic or data portion of the executable is stored in memory (or swap/paging files) for every user or instance of the executable. OpenEdge dynamic memory allocation is estimated based on the number of users and a some of the startup parameters for the brokers.
Estimate the amount of memory used by the database broker, at 110 percent to the database buffers parameter (-B). However, if you have a high value for lock table entries (-L) or index cursors (-c), you must increase the estimate. Record locks consume 14 to 18 bytes each, and index cursors consume 64 bytes each. Also, if you have a very low setting for database buffers (less than 2000), the overhead for the other parameters will be greater than 10 percent of the -B value.
For example, if database buffers (-B) are set to 20,000 on an 8KB-block-size database, you allocate 160,000KB in database buffers. If you add 10 percent of this amount, your total allocation will be approximately 176,000KB, or 176MB for the database broker.
Remote client servers are estimated to use approximately 3MB to 5MB. The number of remote client servers is limited by the -Mm parameter. The default number is 4.
Client processes will vary, depending on the startup options chosen. However, with average settings for –mmax and –Bt, the new memory allocated per process will be 5MB to 10MB. This range applies to application server processes, too. Remote users generally use more memory (10MB to 20MB per process) because they require larger settings for –mmax and –Bt to provide acceptable performance across the network. The memory requirements for a remote user (that is, –mmax and –Bt settings) do not impact the memory requirements on the host.
Example memory budget
Here is an example of a machine with 1GB of RAM, 50 local users, and one 8KB-block-size database using 10,000 database buffers.
Operating system memory:
OpenEdge memory:
Total memory requirement: 582MB to 832MB.
The system can run without significant paging, allowing you to use the additional memory for other applications or to further increase the memory utilization for OpenEdge by increasing database broker parameters, like –B. Once the broker is as efficient as possible, you can look into increasing local user parameters like –mmax.
In many cases there will be third-party applications running on the system, too. Consider the memory used by these additional applications to accurately determine memory estimates.